Controlling devices over the Internet requires considerable knowledge across several fields. For example, to manipulate a device via the Internet, such as via an interactive Web site, a person may need to understand Web site design, networking, server management, communication protocols, multiple programming languages, embedded systems, and mechatronics. As such, the vast majority of people do not possess the necessary skills to configure a system allowing for the control of a device via the Internet.
In addition to the knowledge required, the hardware requirements of such an undertaking are prohibitive to small entities, such as individuals or small organizations. Current Internet-based device monitoring and control interface systems are meant for industrial applications. The expense and power requirements of industrial equipment are too great to make this a realistic solution. In addition, the equipment is rather large, consuming large cabinets and racks impractical for home or small business use. This solution may also require familiarity with the equipment's programming interface and custom cabling and hardware.
Other current solutions for Internet-based device control require a person to establish a server which accepts requests from the Internet. These servers are typically embedded Web servers that host their own Web pages for device interaction. The Internet connections employed by small entities are typically based on dynamic internet protocol (IP) address assignment. Hosting a server on a dynamic IP address is problematic because the IP address may change, causing a disruption in the server's connection to the Internet and preventing a remote user from contacting the server. Additionally, hosting a server requires the user to configure the local network. An average person may have difficulty with the intricacies of remapping router ports and other such matters. Furthermore, some individuals may not have access to their Internet connection networking equipment, such as people living in apartment complexes or dormitories. Internet Service Providers (ISPs) may cause additional problems for server-based architectures. Many ISPs frown upon users hosting servers and may block ports used for this.
Both the aforementioned industrial and server solutions lack convenient mechanisms for Web site and Web service integration. Considerable knowledge of Hypertext Markup Language (HTML), JavaScript, and Application Programming Interfaces (APIs) is required to place any controls on a Web site or to establish access via a Web service (such as a social network), web application, desktop program, mobile application, etc. As a result, such a solution requires customized Web site integration which, again, is beyond the skills of the average user.
One particular control procedure, Wake-on-LAN (WOL), pertains to activating (“waking”) a device, such as a computer, from a remote location. An individual or an organization may wish to employ WOL to save on the costs accrued from running unnecessary devices full time. For example, a field agent may require occasional remote access to a computer at his company's headquarters. WOL technology would allow the company to only pay for the energy used by the computer when it was in use by the remote field agent. However, current systems do not allow for convenient or cost-effective WOL configurations, particularly when the device needs to be activated from outside the local network. For example, WOL is often accomplished by a user remotely connecting to a peer computer on a network and having it send a special network message, called a “magic packet,” to the desired computer on the same network. The magic packet contains the media access control (MAC) address of the desired computer, thereby identifying it. This configuration requires that the peer computer be left continuously activated in order to activate other computers and, thus, does not resolve the problem, as power must be provided to the peer computer.
Additional obstacles arise when a user wishes to use the Internet to interact with devices that are not in close proximity to a network connection (e.g., a router) or a network interface. Using wires to connect nonadjacent devices is often troublesome and impractical. For example, if a user's Internet connection is located on the ground floor of a building, and the device he wishes to interact with is located on the second floor, the user would be required to run wire through the building's structure in some fashion. A user may seek to avoid the problems of wired connections by connecting the nonadjacent device via a wireless connection; however a wireless connection poses problems as well. The user may need to configure the device so that it interacts properly with a network connection, a server, and/or a mechanism used to interact with the device via the network. This can be a daunting task for an average user.
What is needed is a convenient mechanism that enables an average person to configure an architecture to control or monitor a device via an Internet-based medium. Furthermore, what is needed is a mechanism for enabling a user to activate an inactive device via an Internet-based medium. Additionally, what is needed is a mechanism for enabling a device for wireless connectivity so that the device may be readily controlled or monitored via an Internet-based medium when the device is nonadjacent to network connection mechanism.